home *** CD-ROM | disk | FTP | other *** search
/ Just Call Me Internet / Just Call Me Internet.iso / docs / protocol / std / std35.txt < prev    next >
Text File  |  1997-09-26  |  31KB  |  1,061 lines
  1.  
  2.  
  3. Network Working Group                    Marshall T. Rose, Dwight E. Cass
  4. Request for Comments: RFC 1006    Northrop Research and Technology Center
  5. Obsoletes: RFC 983                                               May 1987
  6.  
  7.  
  8.  
  9.                 ISO Transport Service on top of the TCP
  10.                                Version: 3
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This memo specifies a standard for the Internet community. Hosts
  16.    on the Internet that choose to implement ISO transport services
  17.    on top of the TCP are expected to adopt and implement this
  18.    standard.  TCP port 102 is reserved for hosts which implement this
  19.    standard.  Distribution of this memo is unlimited.
  20.  
  21.    This memo specifies version 3 of the protocol and supersedes
  22.    [RFC983].  Changes between the protocol as described in Request for
  23.    Comments 983 and this memo are minor, but are unfortunately
  24.    incompatible.
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. M. Rose & D. Cass                                               [Page 1]
  58.  
  59. RFC 1006                                                        May 1987
  60.  
  61.  
  62. 1.  Introduction and Philosophy
  63.  
  64.  
  65.       The Internet community has a well-developed, mature set of
  66.       transport and internetwork protocols (TCP/IP), which are quite
  67.       successful in offering network and transport services to
  68.       end-users. The CCITT and the ISO have defined various session,
  69.       presentation, and application recommendations which have been
  70.       adopted by the international community and numerous vendors.
  71.       To the largest extent possible, it is desirable to offer these
  72.       higher level directly in the ARPA Internet, without disrupting
  73.       existing facilities.  This permits users to develop expertise
  74.       with ISO and CCITT applications which previously were not
  75.       available in the ARPA Internet.  It also permits a more
  76.       graceful convergence and transition strategy from
  77.       TCP/IP-based networks to ISO-based networks in the
  78.       medium-and long-term.
  79.  
  80.       There are two basic approaches which can be taken when "porting"
  81.       an ISO or CCITT application to a TCP/IP environment.  One
  82.       approach is to port each individual application separately,
  83.       developing local protocols on top of the TCP.  Although this is
  84.       useful in the short-term (since special-purpose interfaces to the
  85.       TCP can be developed quickly), it lacks generality.
  86.  
  87.       A second approach is based on the observation that both the ARPA
  88.       Internet protocol suite and the ISO protocol suite are both
  89.       layered systems (though the former uses layering from a more
  90.       pragmatic perspective).  A key aspect of the layering principle
  91.       is that of layer-independence.  Although this section is
  92.       redundant for most readers, a slight bit of background material
  93.       is necessary to introduce this concept.
  94.  
  95.       Externally, a layer is defined by two definitions:
  96.  
  97.          a service-offered definition, which describes the services
  98.          provided by the layer and the interfaces it provides to
  99.          access those services; and,
  100.  
  101.          a service-required definitions, which describes the services
  102.          used by the layer and the interfaces it uses to access those
  103.          services.
  104.  
  105.       Collectively, all of the entities in the network which co-operate
  106.       to provide the service are known as the service-provider.
  107.       Individually, each of these entities is known as a service-peer.
  108.  
  109.       Internally, a layer is defined by one definition:
  110.  
  111.           a protocol definition, which describes the rules which each
  112.           service-peer uses when communicating with other service-peers.
  113.  
  114.  
  115.  
  116. M. Rose & D. Cass                                               [Page 2]
  117.  
  118. RFC 1006                                                        May 1987
  119.  
  120.  
  121.       Putting all this together, the service-provider uses the protocol
  122.       and services from the layer below to offer the its service to the
  123.       layer above.  Protocol verification, for instance, deals with
  124.       proving that this in fact happens (and is also a fertile field
  125.       for many Ph.D. dissertations in computer science).
  126.  
  127.       The concept of layer-independence quite simply is:
  128.  
  129.           IF one preserves the services offered by the service-provider
  130.  
  131.           THEN the service-user is completely naive with respect to the
  132.           protocol which the service-peers use
  133.  
  134.  
  135.       For the purposes of this memo, we will use the layer-independence
  136.       to define a Transport Service Access Point (TSAP) which appears
  137.       to be identical to the services and interfaces offered by the
  138.       ISO/CCITT TSAP (as defined in [ISO8072]), but we will in fact
  139.       implement the ISO TP0 protocol on top of TCP/IP (as defined in
  140.       [RFC793,RFC791]), not on top of the the ISO/CCITT network
  141.       protocol.  Since the transport class 0 protocol is used over the
  142.       TCP/IP connection, it achieves identical functionality as
  143.       transport class 4.  Hence, ISO/CCITT higher level layers (all
  144.       session, presentation, and application entities) can operate
  145.       fully without knowledge of the fact that they are running on a
  146.       TCP/IP internetwork.
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175. M. Rose & D. Cass                                               [Page 3]
  176.  
  177. RFC 1006                                                        May 1987
  178.  
  179.  
  180. 2.  Motivation
  181.  
  182.  
  183.       In migrating from the use of TCP/IP to the ISO protocols, there
  184.       are several strategies that one might undertake.  This memo was
  185.       written with one particular strategy in mind.
  186.  
  187.       The particular migration strategy which this memo uses is based
  188.       on the notion of gatewaying between the TCP/IP and ISO protocol
  189.       suites at the transport layer.  There are two strong arguments
  190.       for this approach:
  191.  
  192.       1.  Experience teaches us that it takes just as long to get good
  193.       implementations of the lower level protocols as it takes to get
  194.       implementations of the higher level ones.  In particular, it has
  195.       been observed that there is still a lot of work being done at the
  196.       ISO network and transport layers.  As a result, implementations
  197.       of protocols above these layers are not being aggressively
  198.       pursued. Thus, something must be done "now" to provide a medium
  199.       in which the higher level protocols can be developed.  Since
  200.       TCP/IP is mature, and essentially provides identical
  201.       functionality, it is an ideal medium to support this development.
  202.  
  203.       2.  Implementation of gateways at the IP and ISO IP layers are
  204.       probably not of general use in the long term.  In effect, this
  205.       would require each Internet host to support both TP4 and TCP.
  206.       As such, a better strategy is to implement a graceful migration
  207.       path from TCP/IP to ISO protocols for the ARPA Internet when the
  208.       ISO protocols have matured sufficiently.
  209.  
  210.       Both of these arguments indicate that gatewaying should occur at
  211.       or above the transport layer service access point.  Further, the
  212.       first argument suggests that the best approach is to perform the
  213.       gatewaying exactly AT the transport service access point to
  214.       maximize the number of ISO layers which can be developed.
  215.  
  216.         NOTE:     This memo does not intend to act as a migration or
  217.                   intercept document.  It is intended ONLY to meet the
  218.                   needs discussed above.  However, it would not be
  219.                   unexpected that the protocol described in this memo
  220.                   might form part of an overall transition plan.  The
  221.                   description of such a plan however is COMPLETELY
  222.                   beyond the scope of this memo.
  223.  
  224.       Finally, in general, building gateways between other layers in the
  225.       TCP/IP and ISO protocol suites is problematic, at best.
  226.  
  227.       To summarize: the primary motivation for the standard described in
  228.       this memo is to facilitate the process of gaining experience with
  229.       higher-level ISO protocols (session, presentation, and
  230.       application). The stability and maturity of TCP/IP are ideal for
  231.  
  232.  
  233.  
  234. M. Rose & D. Cass                                               [Page 4]
  235.  
  236. RFC 1006                                                        May 1987
  237.  
  238.  
  239.       providing solid transport services independent of actual
  240.       implementation.
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293. M. Rose & D. Cass                                               [Page 5]
  294.  
  295. RFC 1006                                                        May 1987
  296.  
  297.  
  298. 3.  The Model
  299.  
  300.  
  301.       The [ISO8072] standard describes the ISO transport service
  302.       definition, henceforth called TP.
  303.  
  304.           ASIDE:    This memo references the ISO specifications rather
  305.                     than the CCITT recommendations.  The differences
  306.                     between these parallel standards are quite small,
  307.                     and can be ignored, with respect to this memo,
  308.                     without loss of generality.  To provide the reader
  309.                     with the relationships:
  310.  
  311.                          Transport service    [ISO8072]       [X.214]
  312.                          Transport protocol   [ISO8073]       [X.224]
  313.                          Session protocol     [ISO8327]       [X.225]
  314.  
  315.  
  316.       The ISO transport service definition describes the services
  317.       offered by the TS-provider (transport service) and the interfaces
  318.       used to access those services.  This memo focuses on how the ARPA
  319.       Transmission Control Protocol (TCP) [RFC793] can be used to offer
  320.       the services and provide the interfaces.
  321.  
  322.  
  323.       +-----------+                                       +-----------+
  324.       |  TS-user  |                                       |  TS-user  |
  325.       +-----------+                                       +-----------+
  326.            |                                                     |
  327.            | TSAP interface                       TSAP interface |
  328.            |  [ISO8072]                                          |
  329.            |                                                     |
  330.       +----------+   ISO Transport Services on the TCP     +----------+
  331.       |  client  |-----------------------------------------|  server  |
  332.       +----------+              (this memo)                +----------+
  333.            |                                                     |
  334.            | TCP interface                         TCP interface |
  335.            |  [RFC793]                                           |
  336.            |                                                     |
  337.  
  338.  
  339.       For expository purposes, the following abbreviations are used:
  340.  
  341.          TS-peer      a process which implements the protocol described
  342.                       by this memo
  343.  
  344.          TS-user      a process talking using the services of a TS-peer
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352. M. Rose & D. Cass                                               [Page 6]
  353.  
  354. RFC 1006                                                        May 1987
  355.  
  356.  
  357.          TS-provider  the black-box entity implementing the protocol
  358.                       described by this memo
  359.  
  360.  
  361.       For the purposes of this memo, which describes version 2 of the
  362.       TSAP protocol, all aspects of [ISO8072] are supported with one
  363.       exception:
  364.  
  365.           Quality of Service parameters
  366.  
  367.  
  368.       In the spirit of CCITT, this is left "for further study".  A
  369.       future version of the protocol will most likely support the QOS
  370.       parameters for TP by mapping these onto various TCP parameters.
  371.  
  372.       The ISO standards do not specify the format of a session port
  373.       (termed a TSAP ID).  This memo mandates the use of the GOSIP
  374.       specification [GOSIP86] for the interpretation of this field.
  375.       (Please refer to Section 5.2, entitled "UPPER LAYERS ADDRESSING".)
  376.  
  377.       Finally, the ISO TSAP is fundamentally symmetric in behavior.
  378.       There is no underlying client/server model.  Instead of a server
  379.       listening on a well-known port, when a connection is established,
  380.       the TS-provider generates an INDICATION event which, presumably
  381.       the TS-user catches and acts upon.  Although this might be
  382.       implemented by having a server "listen" by hanging on the
  383.       INDICATION event, from the perspective of the ISO TSAP, all TS-
  384.       users just sit around in the IDLE state until they either generate
  385.       a REQUEST or accept an INDICATION.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411. M. Rose & D. Cass                                               [Page 7]
  412.  
  413. RFC 1006                                                        May 1987
  414.  
  415.  
  416. 4.  The Primitives
  417.  
  418.  
  419.       The protocol assumes that the TCP[RFC793] offers the following
  420.       service primitives:
  421.  
  422.                                     Events
  423.  
  424.          connected       - open succeeded (either ACTIVE or PASSIVE)
  425.  
  426.          connect fails   - ACTIVE open failed
  427.  
  428.          data ready      - data can be read from the connection
  429.  
  430.          errored         - the connection has errored and is now closed
  431.  
  432.          closed          - an orderly disconnection has started
  433.  
  434.                                      Actions
  435.  
  436.          listen on port  - PASSIVE open on the given port
  437.  
  438.          open port       - ACTIVE open to the given port
  439.  
  440.          read data       - data is read from the connection
  441.  
  442.          send data       - data is sent on the connection
  443.  
  444.          close           - the connection is closed (pending data is
  445.                            sent)
  446.  
  447.  
  448. This memo describes how to use these services to emulate the following
  449. service primitives, which are required by [ISO8073]:
  450.  
  451.                                  Events
  452.  
  453.          N-CONNECT.INDICATION
  454.                           - An NS-user (responder) is notified that
  455.                             connection establishment is in progress
  456.  
  457.  
  458.          N-CONNECT.CONFIRMATION
  459.                           - An NS-user (responder) is notified that
  460.                             the connection has been established
  461.  
  462.          N-DATA.INDICATION
  463.                           - An NS-user is notified that data can be
  464.                             read from the connection
  465.  
  466.  
  467.  
  468.  
  469.  
  470. M. Rose & D. Cass                                               [Page 8]
  471.  
  472. RFC 1006                                                        May 1987
  473.  
  474.  
  475.          N-DISCONNECT.INDICATION
  476.                           - An NS-user is notified that the connection
  477.                             is closed
  478.  
  479.                                 Actions
  480.  
  481.          N-CONNECT.REQUEST
  482.                           - An NS-user (initiator) indicates that it
  483.                             wants to establish a connection
  484.  
  485.          N-CONNECT.RESPONSE
  486.                           - An NS-user (responder) indicates that it
  487.                             will honor the request
  488.  
  489.          N-DATA.REQUEST   - An NS-user sends data
  490.  
  491.          N-DISCONNECT.REQUEST
  492.                           - An NS-user indicates that the connection
  493.                             is to be closed
  494.  
  495.       The protocol offers the following service primitives, as defined
  496.       in [ISO8072], to the TS-user:
  497.  
  498.                                     Events
  499.  
  500.          T-CONNECT.INDICATION
  501.                           - a TS-user (responder) is notified that
  502.                             connection establishment is in progress
  503.  
  504.          T-CONNECT.CONFIRMATION
  505.                           - a TS-user (initiator) is notified that the
  506.                             connection has been established
  507.  
  508.          T-DATA.INDICATION
  509.                           - a TS-user is notified that data can be read
  510.                             from the connection
  511.  
  512.          T-EXPEDITED DATA.INDICATION
  513.                           - a TS-user is notified that "expedited" data
  514.                             can be read from the connection
  515.  
  516.          T-DISCONNECT.INDICATION
  517.                           - a TS-user is notified that the connection
  518.                             is closed
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529. M. Rose & D. Cass                                               [Page 9]
  530.  
  531. RFC 1006                                                        May 1987
  532.  
  533.  
  534.                                 Actions
  535.  
  536.          T-CONNECT.REQUEST
  537.                           - a TS-user (initiator) indicates that it
  538.                             wants to establish a connection
  539.  
  540.          T-CONNECT.RESPONSE
  541.                           - a TS-user (responder) indicates that it
  542.                             will honor the request
  543.  
  544.          T-DATA.REQUEST   - a TS-user sends data
  545.  
  546.          T-EXPEDITED DATA.REQUEST
  547.                           - a TS-user sends "expedited" data
  548.  
  549.          T-DISCONNECT.REQUEST
  550.                           - a TS-user indicates that the connection
  551.                             is to be closed
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588. M. Rose & D. Cass                                              [Page 10]
  589.  
  590. RFC 1006                                                        May 1987
  591.  
  592.  
  593. 5.  The Protocol
  594.  
  595.  
  596.       The protocol specified by this memo is identical to the protocol
  597.       for ISO transport class 0, with the following exceptions:
  598.  
  599.             - for testing purposes, initial data may be exchanged
  600.               during connection establishment
  601.  
  602.             - for testing purposes, an expedited data service is
  603.               supported
  604.  
  605.             - for performance reasons, a much larger TSDU size is
  606.               supported
  607.  
  608.             - the network service used by the protocol is provided
  609.               by the TCP
  610.  
  611.  
  612.       The ISO transport protocol exchanges information between peers in
  613.       discrete units of information called transport protocol data units
  614.       (TPDUs).  The protocol defined in this memo encapsulates these
  615.       TPDUs in discrete units called TPKTs.  The structure of these
  616.       TPKTs and their relationship to TPDUs are discussed in the next
  617.       section.
  618.  
  619.       PRIMITIVES
  620.  
  621.          The mapping between the TCP service primitives and the service
  622.          primitives expected by transport class 0 are quite straight-
  623.          forward:
  624.  
  625.                    network service              TCP
  626.                    ---------------              ---
  627.                    CONNECTION ESTABLISHMENT
  628.  
  629.                        N-CONNECT.REQUEST        open completes
  630.  
  631.                        N-CONNECT.INDICATION     listen (PASSIVE open)
  632.                                                 finishes
  633.  
  634.                        N-CONNECT.RESPONSE       listen completes
  635.  
  636.                        N-CONNECT.CONFIRMATION   open (ACTIVE open)
  637.                                                 finishes
  638.  
  639.                    DATA TRANSFER
  640.  
  641.                        N-DATA.REQUEST           send data
  642.  
  643.                        N-DATA.INDICATION        data ready followed by
  644.  
  645.  
  646.  
  647. M. Rose & D. Cass                                              [Page 11]
  648.  
  649. RFC 1006                                                        May 1987
  650.  
  651.  
  652.                                                 read data
  653.  
  654.                    CONNECTION RELEASE
  655.  
  656.                        N-DISCONNECT.REQUEST     close
  657.  
  658.                        N-DISCONNECT.INDICATION  connection closes or
  659.                                                 errors
  660.  
  661.           Mapping parameters is also straight-forward:
  662.  
  663.                      network service             TCP
  664.                      ---------------             ---
  665.                      CONNECTION RELEASE
  666.  
  667.                          Called address          server's IP address
  668.                                                  (4 octets)
  669.  
  670.                          Calling address         client's IP address
  671.                                                  (4 octets)
  672.  
  673.                          all others              ignored
  674.  
  675.                       DATA TRANSFER
  676.  
  677.                          NS-user data (NSDU)     data
  678.  
  679.                       CONNECTION RELEASE
  680.  
  681.                          all parameters          ignored
  682.  
  683.  
  684.  
  685.       CONNECTION ESTABLISHMENT
  686.  
  687.           The elements of procedure used during connection establishment
  688.           are identical to those presented in [ISO8073], with three
  689.           exceptions.
  690.  
  691.           In order to facilitate testing, the connection request and
  692.           connection confirmation TPDUs may exchange initial user data,
  693.           using the user data fields of these TPDUs.
  694.  
  695.           In order to experiment with expedited data services, the
  696.           connection request and connection confirmation TPDUs may
  697.           negotiate the use of expedited data transfer using the
  698.           negotiation mechanism specified in [ISO8073] is used (e.g.,
  699.           setting the "use of transport expedited data transfer service"
  700.           bit in the "Additional Option Selection" variable part). The
  701.           default is not to use the transport expedited data transfer
  702.           service.
  703.  
  704.  
  705.  
  706. M. Rose & D. Cass                                              [Page 12]
  707.  
  708. RFC 1006                                                        May 1987
  709.  
  710.  
  711.           In order to achieve good performance, the default TPDU size is
  712.           65531 octets, instead of 128 octets.  In order to negotiate a
  713.           smaller (standard) TPDU size, the negotiation mechanism
  714.           specified in [ISO8073] is used (e.g., setting the desired bit
  715.           in the "TPDU Size" variable part).
  716.  
  717.           To perform an N-CONNECT.REQUEST action, the TS-peer performs
  718.           an active open to the desired IP address using TCP port 102.
  719.           When the TCP signals either success or failure, this results
  720.           in an N-CONNECT.INDICATION action.
  721.  
  722.           To await an N-CONNECT.INDICATION event, a server listens on
  723.           TCP port 102.  When a client successfully connects to this
  724.           port, the event occurs, and an implicit N-CONNECT.RESPONSE
  725.           action is performed.
  726.  
  727.               NOTE:      In most implementations, a single server will
  728.                          perpetually LISTEN on port 102, handing off
  729.                          connections as they are made
  730.  
  731. DATA TRANSFER
  732.  
  733.       The elements of procedure used during data transfer are identical
  734.       to those presented in [ISO8073], with one exception: expedited
  735.       data may be supported (if so negotiated during connection
  736.       establishment) by sending a modified ED TPDU (described below).
  737.       The TPDU is sent on the same TCP connection as all of the other
  738.       TPDUs. This method, while not faithful to the spirit of [ISO8072],
  739.       is true to the letter of the specification.
  740.  
  741.       To perform an N-DATA.REQUEST action, the TS-peer constructs the
  742.       desired TPKT and uses the TCP send data primitive.
  743.  
  744.       To trigger an N-DATA.INDICATION action, the TCP indicates that
  745.       data is ready and a TPKT is read using the TCP read data
  746.       primitive.
  747.  
  748. CONNECTION RELEASE
  749.  
  750.    To perform an N-DISCONNECT.REQUEST action, the TS-peer simply closes
  751.    the TCP connection.
  752.  
  753.    If the TCP informs the TS-peer that the connection has been closed or
  754.    has errored, this indicates an N-DISCONNECT.INDICATION event.
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765. M. Rose & D. Cass                                              [Page 13]
  766.  
  767. RFC 1006                                                        May 1987
  768.  
  769.  
  770. 6.  Packet Format
  771.  
  772.  
  773.       A fundamental difference between the TCP and the network service
  774.       expected by TP0 is that the TCP manages a continuous stream of
  775.       octets, with no explicit boundaries.  The TP0 expects information
  776.       to be sent and delivered in discrete objects termed network
  777.       service data units (NSDUs).  Although other classes of transport
  778.       may combine more than one TPDU inside a single NSDU, transport
  779.       class 0 does not use this facility.  Hence, an NSDU is identical
  780.       to a TPDU for the purposes of our discussion.
  781.  
  782.       The protocol described by this memo uses a simple packetization
  783.       scheme in order to delimit TPDUs.  Each packet, termed a TPKT, is
  784.       viewed as an object composed of an integral number of octets, of
  785.       variable length.
  786.  
  787.           NOTE:       For the purposes of presentation, these objects are
  788.                       shown as being 4 octets (32 bits wide).  This
  789.                       representation is an artifact of the style of this
  790.                       memo and should not be interpreted as requiring
  791.                       that a TPKT be a multiple of 4 octets in length.
  792.  
  793.       A TPKT consists of two parts:  a packet-header and a TPDU.  The
  794.       format of the header is constant regardless of the type of packet.
  795.       The format of the packet-header is as follows:
  796.  
  797.         0                   1                   2                   3
  798.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  799.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  800.        |      vrsn     |    reserved   |          packet length        |
  801.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  802.  
  803.       where:
  804.  
  805.       vrsn                         8 bits
  806.  
  807.       This field is always 3 for the version of the protocol described in
  808.       this memo.
  809.  
  810.       packet length                16 bits (min=7, max=65535)
  811.  
  812.       This field contains the length of entire packet in octets,
  813.       including packet-header.  This permits a maximum TPDU size of
  814.       65531 octets.  Based on the size of the data transfer (DT) TPDU,
  815.       this permits a maximum TSDU size of 65524 octets.
  816.  
  817.       The format of the TPDU is defined in [ISO8073].  Note that only
  818.       TPDUs formatted for transport class 0 are exchanged (different
  819.       transport classes may use slightly different formats).
  820.  
  821.  
  822.  
  823.  
  824. M. Rose & D. Cass                                              [Page 14]
  825.  
  826. RFC 1006                                                        May 1987
  827.  
  828.  
  829.       To support expedited data, a non-standard TPDU, for expedited data
  830.       is permitted.  The format used for the ED TPDU is nearly identical
  831.       to the format for the normal data, DT, TPDU.  The only difference
  832.       is that the value used for the TPDU's code is ED, not DT:
  833.  
  834.        0                   1                   2                   3
  835.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  836.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  837.       | header length | code  |credit |TPDU-NR and EOT|   user data   |
  838.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  839.       |      ...      |      ...      |      ...      |      ...      |
  840.       |      ...      |      ...      |      ...      |      ...      |
  841.       |      ...      |      ...      |      ...      |      ...      |
  842.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  843.  
  844.       After the credit field (which is always ZERO on output and ignored
  845.       on input), there is one additional field prior to the user data.
  846.  
  847.       TPDU-NR and EOT         8 bits
  848.  
  849.       Bit 7 (the high-order bit, bit mask 1000 0000) indicates the end
  850.       of a TSDU.  All other bits should be ZERO on output and ignored on
  851.       input.
  852.  
  853.       Note that the TP specification limits the size of an expedited
  854.       transport service data unit (XSDU) to 16 octets.
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883. M. Rose & D. Cass                                              [Page 15]
  884.  
  885. RFC 1006                                                        May 1987
  886.  
  887.  
  888. 7.  Comments
  889.  
  890.  
  891.       Since the release of RFC983 in April of 1986, we have gained much
  892.       experience in using ISO transport services on top of the TCP.  In
  893.       September of 1986, we introduced the use of version 2 of the
  894.       protocol, based mostly on comments from the community.
  895.  
  896.       In January of 1987, we observed that the differences between
  897.       version 2 of the protocol and the actual transport class 0
  898.       definition were actually quite small.  In retrospect, this
  899.       realization took much longer than it should have:  TP0 is is meant
  900.       to run over a reliable network service, e.g., X.25. The TCP can be
  901.       used to provide a service of this type, and, if no one complains
  902.       too loudly, one could state that this memo really just describes a
  903.       method for encapsulating TPO inside of TCP!
  904.  
  905.       The changes in going from version 1 of the protocol to version 2
  906.       and then to version 3 are all relatively small. Initially, in
  907.       describing version 1, we decided to use the TPDU formats from the
  908.       ISO transport protocol.  This naturally led to the evolution
  909.       described above.
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942. M. Rose & D. Cass                                              [Page 16]
  943.  
  944. RFC 1006                                                        May 1987
  945.  
  946.  
  947. 8. References
  948.  
  949.  
  950.    [GOSIP86]    The U.S. Government OSI User's Committee.
  951.                 "Government Open Systems Interconnection Procurement
  952.                 (GOSIP) Specification for Fiscal years 1987 and
  953.                 1988." (December, 1986) [draft status]
  954.  
  955.    [ISO8072]    ISO.
  956.                 "International Standard 8072.  Information Processing
  957.                 Systems -- Open Systems Interconnection: Transport
  958.                 Service Definition."
  959.                 (June, 1984)
  960.  
  961.    [ISO8073]    ISO.
  962.                 "International Standard 8073.  Information Processing
  963.                 Systems -- Open Systems Interconnection: Transport
  964.                 Protocol Specification."
  965.                 (June, 1984)
  966.  
  967.    [ISO8327]    ISO.
  968.                 "International Standard 8327.  Information Processing
  969.                 Systems -- Open Systems Interconnection: Session
  970.                 Protocol Specification."
  971.                 (June, 1984)
  972.  
  973.    [RFC791]     Internet Protocol.
  974.                 Request for Comments 791 (MILSTD 1777)
  975.                 (September, 1981)
  976.  
  977.    [RFC793]     Transmission Control Protocol.
  978.                 Request for Comments 793 (MILSTD 1778)
  979.                 (September, 1981)
  980.  
  981.    [RFC983]     ISO Transport Services on Top of the TCP.
  982.                 Request for Comments 983
  983.                 (April, 1986)
  984.  
  985.    [X.214]      CCITT.
  986.                 "Recommendation X.214.  Transport Service Definitions
  987.                 for Open Systems Interconnection (OSI) for CCITT
  988.                 Applications."
  989.                 (October, 1984)
  990.  
  991.    [X.224]      CCITT.
  992.                 "Recommendation X.224.  Transport Protocol
  993.                 Specification for Open Systems Interconnection (OSI)
  994.                 for CCITT Applications." (October, 1984)
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001. M. Rose & D. Cass                                              [Page 17]
  1002.  
  1003. RFC 1006                                                        May 1987
  1004.  
  1005.  
  1006.    [X.225]      CCITT.
  1007.                 "Recommendation X.225.  Session Protocol Specification
  1008.                 for Open Systems Interconnection (OSI) for CCITT
  1009.                 Applications."
  1010.                 (October, 1984)
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060. M. Rose & D. Cass                                              [Page 18]
  1061.